src/handlers/terminal-handlers.ts (1)

50-55: Add argument validation to maintain consistent handler pattern

Unlike the other handlers in this file that validate arguments using their respective schemas before passing them to implementation functions, handleSendInput directly passes the arguments to sendInput without validation.

While sendInput does perform its own validation (as seen in the provided code snippet), it would be more consistent to follow the established pattern:

export async function handleSendInput(args: unknown): Promise<ServerResult> {
-    return sendInput(args);
+    const parsed = SendInputArgsSchema.parse(args);
+    return sendInput(parsed);
}

test/simple-python-test.js (2)

8-71: Consider replacing fixed delay with a more robust waiting mechanism

The fixed delay on line 55 could be brittle as Python processing time might vary across environments.

-  // Wait a moment for Python to process
-  console.log("Waiting for processing...");
-  await new Promise(resolve => setTimeout(resolve, 500));
+  // Wait for Python to process and show the prompt
+  console.log("Waiting for Python prompt...");
+  await readOutput({ 
+    pid, 
+    waitForPrompt: true, 
+    timeout_ms: 2000 
+  });

---

72-73: Consider adding process exit codes for test integration

Adding process exit codes would make this script more suitable for automated test pipelines.

 simplePythonTest();
+  .then(() => {
+    console.log("Test completed successfully");
+    process.exit(0);
+  })
+  .catch(error => {
+    console.error("Test failed:", error);
+    process.exit(1);
+  });

test/test-enhanced-repl.js (1)

41-43: Replace fixed delay with prompt-based waiting

Similar to the previous file, using a fixed delay could be brittle. Since you're already importing readOutput with the appropriate capability, consider using it to wait for the prompt instead.

-  // Wait a moment for Python to process
-  console.log("Waiting for output...");
-  await new Promise(resolve => setTimeout(resolve, 1000));
+  // Wait for Python to process and show the prompt
+  console.log("Waiting for Python prompt...");
+  await readOutput({ 
+    pid, 
+    waitForPrompt: true, 
+    timeout_ms: 2000 
+  });

src/tools/enhanced-read-output.js (1)

66-66: Fix string concatenation in the output message.

The conditional for timeoutReached is being concatenated directly to the 'No new output available' string without a space, which will result in text like "No new output available(timeout reached)" instead of "No new output available (timeout reached)".

-      text: output || 'No new output available' + (timeoutReached ? ' (timeout reached)' : '')
+      text: output || ('No new output available' + (timeoutReached ? ' (timeout reached)' : ''))

test/test-repl-interaction.js (1)

149-205: Node.js REPL test has the same improvement opportunities as the Python test.

The Node.js test implementation is similar to the Python test and could benefit from the same improvements:

1. Use optional chaining for the output check:

- if (output && output.includes(`NODE_REPL_TEST_VALUE: ${testValue * 3}`)) {
+ if (output?.includes(`NODE_REPL_TEST_VALUE: ${testValue * 3}`)) {

2. Consider adding more resilience for different environments where the Node.js REPL might take longer to respond.

🧰 Tools

🪛 Biome (1.9.4)

[error] 199-200: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

test/test-node-repl.js (2)

84-86: Add error handling for debug log write failure.

The debug log write error is logged but doesn't affect the test outcome. Consider adding more robust error handling here.

- fs.writeFile(debugFile, debugLog).catch(err => {
-   console.error(`Failed to write debug log: ${err.message}`);
- });
+ fs.writeFile(debugFile, debugLog)
+   .then(() => {
+     log(`${colors.green}Debug log saved successfully${colors.reset}`);
+   })
+   .catch(err => {
+     log(`${colors.red}Failed to write debug log: ${err.message}${colors.reset}`);
+   });

---

153-166: Consider adding timeout protection for the entire test.

While individual operations have sleep timers, the overall test doesn't have a timeout protection. For better reliability in CI environments, consider adding an overall timeout.

+ // Add a timeout promise to prevent hanging tests
+ const testWithTimeout = Promise.race([
+   testNodeREPL(),
+   new Promise((_, reject) => 
+     setTimeout(() => reject(new Error('Test timeout exceeded')), 30000)
+   )
+ ]);
+
- testNodeREPL()
+ testWithTimeout

test/repl-via-terminal-example.js (1)

6-11: Good import structure, but consider using the enhanced version for consistency.

The imports are well-organized, but I notice you're importing sendInput from ../dist/tools/send-input.js while the enhanced-repl-example.js file imports from ../dist/tools/enhanced-send-input.js. Consider using the enhanced version for consistent behavior across examples.

- import { sendInput } from '../dist/tools/send-input.js';
+ import { sendInput } from '../dist/tools/enhanced-send-input.js';

test/test-repl-tools.js (2)

76-101: Consider asserting specific output content in Python REPL test.

The test verifies that operations succeed but doesn't validate the actual content of the output. Consider adding assertions to check that the output contains expected values.

const result1 = await replManager.executeCode(pid, 'print("Hello from Python!")');
console.log(`${colors.blue}Result: ${JSON.stringify(result1)}${colors.reset}`);
+ // Verify output contains expected text
+ const outputContainsHello = result1.output && result1.output.includes("Hello from Python!");
+ if (!outputContainsHello) {
+   console.log(`${colors.red}× Output doesn't contain expected text${colors.reset}`);
+   return false;
+ }

---

97-101: Add waitForPrompt option for consistency with Node.js example.

The Python REPL test doesn't use the waitForPrompt option that's used in the Node.js test. Consider adding it for consistency.

const result2 = await replManager.executeCode(pid, pythonCode, { 
  multiline: true,
- timeout: 5000
+ timeout: 5000,
+ waitForPrompt: true
});

test/enhanced-repl-example.js (1)

1-150: This example demonstrates better practices than repl-via-terminal-example.js.

This file demonstrates more robust REPL interaction patterns by using timeouts and wait_for_prompt consistently. Consider updating the other example file to match these practices for consistency.

src/terminal-manager.ts (2)

19-43: Well-implemented sendInputToProcess method with proper error handling.

This method is well-designed with proper error handling and validation. The newline handling for REPL compatibility is a nice touch.

Consider adding a small enhancement to handle binary data:

- const inputWithNewline = input.endsWith('\n') ? input : input + '\n';
- session.process.stdin.write(inputWithNewline);
+ // Ensure input is a string
+ const inputStr = typeof input === 'string' ? input : String(input);
+ const inputWithNewline = inputStr.endsWith('\n') ? inputStr : inputStr + '\n';
+ session.process.stdin.write(inputWithNewline);

---

25-43: Consider returning more detailed error information.

The method currently returns a boolean indicating success/failure. Consider enhancing it to return more detailed error information.

- sendInputToProcess(pid: number, input: string): boolean {
+ sendInputToProcess(pid: number, input: string): { success: boolean; error?: string } {
  const session = this.sessions.get(pid);
  if (!session) {
-   return false;
+   return { success: false, error: `No active session found for PID ${pid}` };
  }
  
  try {
    if (session.process.stdin && !session.process.stdin.destroyed) {
      // Ensure input ends with a newline for most REPLs
      const inputWithNewline = input.endsWith('\n') ? input : input + '\n';
      session.process.stdin.write(inputWithNewline);
-     return true;
+     return { success: true };
    }
-   return false;
+   return { success: false, error: 'Process stdin is not available or is destroyed' };
  } catch (error) {
    console.error(`Error sending input to process ${pid}:`, error);
-   return false;
+   return { 
+     success: false, 
+     error: error instanceof Error ? error.message : String(error)
+   };
  }
}

src/tools/enhanced-send-input.js (2)

45-93: Consider expanding prompt detection patterns.

The prompt detection logic is limited to a few common REPL patterns. It might be worth considering a more extensive set of patterns or making them configurable.

- const promptPatterns = [/^>\s*$/, /^>>>\s*$/, /^\.{3}\s*$/]; // Common REPL prompts
+ const promptPatterns = [
+   /^>\s*$/,           // Node.js
+   /^>>>\s*$/,         // Python primary prompt
+   /^\.{3}\s*$/,       // Python continuation prompt
+   /^irb[^>]*>\s*/,    // Ruby IRB
+   /^php > /,          // PHP interactive mode
+   /^scala> /,         // Scala REPL
+   /^In \[\d+\]: /     // IPython/Jupyter
+ ]; // Common REPL prompts

---

49-70: Consider making the polling interval configurable.

The polling interval is hardcoded at 100ms. For different REPL environments or network conditions, it might be beneficial to make this configurable.

- const interval = setInterval(() => {
+ const pollingInterval = args.polling_interval || 100; // Default 100ms
+ const interval = setInterval(() => {
  // ...existing code...
- }, 100); // Check every 100ms
+ }, pollingInterval); // Check at configured interval

This would require updating the schema as well:

// In SendInputArgsSchema
polling_interval: z.number().optional(),

src/server.ts (1)

343-347: Consider enhancing the tool description.

While the description is clear about the tool's purpose, it could benefit from mentioning the optional parameters like wait_for_prompt and timeout_ms to make their availability more obvious to users.

- description: "Send input to a running terminal session. Ideal for interactive REPL environments like Python, Node.js, or any other shell that expects user input.",
+ description: "Send input to a running terminal session. Ideal for interactive REPL environments like Python, Node.js, or any other shell that expects user input. Supports optional 'wait_for_prompt' to wait for REPL response and 'timeout_ms' to set maximum wait time.",

docs/repl-with-terminal.md (1)

48-70: Consider mentioning the enhanced wait_for_prompt feature.

This section explains manual waiting with delays, but doesn't mention the enhanced wait_for_prompt feature documented in enhanced-repl-terminal.md. Consider adding a reference to this feature for a more complete picture.

### 3. Sending Code to the REPL

Use the `send_input` function to send code to the REPL, making sure to include a newline at the end:

+ > **Note:** For more advanced features like automatic waiting for REPL prompts, see the "Enhanced Terminal Commands for REPL Environments" documentation.
+

docs/enhanced-repl-terminal.md (2)

50-81: Missing article in section heading.

There's a minor grammatical issue in the description after the heading.

### 3. Sending Code to the REPL and Waiting for Response

- Use the enhanced `send_input` function to send code to the REPL and wait for the response:
+ Use the enhanced `send_input` function to send code to the REPL and wait for the response:

The static analysis tool suggested adding "a" before "enhanced", but this is a false positive. The sentence is grammatically correct as is because "enhanced" is an adjective modifying the noun "function".

🧰 Tools

🪛 LanguageTool

[uncategorized] ~81-~81: You might be missing the article “a” here.
Context: ...ending Code to the REPL and Waiting for Response Use the enhanced send_input function...

(AI_EN_LECTOR_MISSING_DETERMINER_A)

---

203-216: Consider adding more robust error handling examples.

The error handling example only checks if the text includes 'timeout reached'. You might want to expand this with more comprehensive error detection.

5. **Error Handling**: Check if a timeout was reached:

   ```javascript
   const result = await sendInput({
     pid,
     input: 'complex_calculation()\n',
     wait_for_prompt: true,
     timeout_ms: 5000
   });
   
   if (result.content[0].text.includes('timeout reached')) {
     console.log('Operation took too long');
   }
+  
+  // Check for other error conditions
+  if (result.isError) {
+    console.error('Error occurred:', result.content[0].text);
+  } else if (result.content[0].text.includes('Error') || 
+             result.content[0].text.includes('Exception')) {
+    console.warn('REPL returned an error:', result.content[0].text);
+  }

</blockquote></details>
<details>
<summary>docs/repl-enhancement-plan.md (10)</summary><blockquote>

`1-3`: **Fix header syntax typo**  
The first line has an extra `w` before the markdown heading. It should read:
```markdown
# REPL Enhancement Plan

---

9-14: Standardize enhancement list formatting
The numbered list mixes inline code and plain text. For clarity, wrap all terminal commands in backticks and consider using bullet points if the order isn’t critical. For example:

- `read_output` supports an optional `timeout_ms`.
- `send_input` supports `timeout_ms` and `wait_for_prompt`.
- Prompt detection improved for common REPL prompts.

---

17-19: Wrap file paths in inline code
File paths should be formatted as code for readability. E.g.:

- ### 1. src/tools/schemas.ts
+ ### 1. `src/tools/schemas.ts`

---

21-33: Ensure code fence language matches the snippet
The schema definitions are TypeScript—using the shorthand ts can make your fences more concise and consistent:

- ```typescript
+ ```ts

---

113-217: Prevent timer leaks and optimize prompt detection
Similarly, in sendInput, you should clear the timeout when resolving on prompt detection:

- const interval = setInterval(...);
- setTimeout(() => { ... }, timeout_ms);
+ const interval = setInterval(...);
+ const timer    = setTimeout(() => {
+   clearInterval(interval);
+   timeoutReached = true;
+   // ...resolve final output
+ }, timeout_ms);

  // upon detecting the prompt:
+ clearInterval(interval);
+ clearTimeout(timer);
  resolve(output);

Additionally, move promptPatterns outside the polling loop to avoid recreating the array on every tick.

---

225-233: Add explicit method visibility and return type
In src/terminal-manager.ts, declare the method as public and keep the return type for clarity:

- getSession(pid: number): TerminalSession | undefined {
+ public getSession(pid: number): TerminalSession | undefined {
    return this.sessions.get(pid);
  }

---

242-338: Include Node.js REPL integration tests
The provided test covers Python but omits Node.js. To ensure multi-environment support, add a similar test that spawns node and validates prompt detection and output handling.

---

342-419: Specify language for example code fences
The example section’s code block is missing a language identifier. For better readability:

- ```
+ ```javascript

---

425-468: Clarify prompt detection in documentation
The docs list >, >>>, and ... but the implementation uses regex anchored to line starts. Note that detection is applied to the last non-empty line’s trimmed output, so whitespace sensitivity matters.

---

469-503: Convert steps to a markdown checklist
Turning the implementation and testing steps into a task list makes progress tracking easier:

- [ ] Update schemas to add new parameters
- [ ] Add `getSession` method to terminal manager
- [ ] Enhance `readOutput` with timeout support
- [ ] Enhance `sendInput` with prompt waiting
- [ ] Create end-to-end REPL tests
- [ ] Update examples and documentation

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

src/utils/process-detection.ts (2)

70-72: Improve prompt detection accuracy.

The current prompt detection might match prompts that appear in the middle of output, not just at the end. Consider checking only the end of the last line for more accurate detection.

-  const detectedPrompt = allPrompts.find(prompt => 
-    lastLine.endsWith(prompt) || lastLine.includes(prompt)
-  );
+  const detectedPrompt = allPrompts.find(prompt => 
+    lastLine.endsWith(prompt)
+  );

---

98-121: Remove redundant prompt check in error handling.

The check for detectedPrompt in the error completion section (lines 105-112) is redundant since detectedPrompt was already determined earlier (lines 70-72) and would be undefined if no prompt was found.

   if (hasErrorCompletion) {
-    // Errors can indicate completion, but check if followed by prompt
-    if (detectedPrompt) {
-      return {
-        isWaitingForInput: true,
-        isFinished: false,
-        isRunning: true,
-        detectedPrompt,
-        lastOutput: output
-      };
-    } else {
-      return {
-        isWaitingForInput: false,
-        isFinished: true,
-        isRunning: false,
-        lastOutput: output
-      };
-    }
+    // Errors typically indicate completion
+    return {
+      isWaitingForInput: false,
+      isFinished: true,
+      isRunning: false,
+      lastOutput: output
+    };
   }

src/tools/improved-process-tools.ts (1)

244-275: Consider cleaning only post-input output.

The cleanProcessOutput function is called with the full accumulated output (line 275), which might remove prompts that appeared before the input was sent. This could make it harder to understand the interaction flow.

Track the output received after sending input separately:

     // Smart waiting with process state detection
-    let output = "";
+    let preInputOutput = terminalManager.getNewOutput(pid) || "";
+    let postInputOutput = "";
     let attempts = 0;
     const maxAttempts = Math.ceil(timeout_ms / 200);
     let processState;
     
     while (attempts < maxAttempts) {
       await new Promise(resolve => setTimeout(resolve, 200));
       
       const newOutput = terminalManager.getNewOutput(pid);
       if (newOutput && newOutput.length > 0) {
-        output += newOutput;
+        postInputOutput += newOutput;
         
         // Analyze current state
-        processState = analyzeProcessState(output, pid);
+        processState = analyzeProcessState(postInputOutput, pid);
         
         // Exit early if we detect the process is waiting for input
         if (processState.isWaitingForInput) {
           break;
         }
         
         // Also exit if process finished
         if (processState.isFinished) {
           break;
         }
       }
       
       attempts++;
     }

     // Clean and format output
-    const cleanOutput = cleanProcessOutput(output, input);
+    const cleanOutput = cleanProcessOutput(postInputOutput, input);

src/server.ts (2)

331-378: Consider reducing description verbosity for maintainability.

While the comprehensive description provides excellent guidance, the extensive repetition of file analysis warnings throughout the tool descriptions could become a maintenance burden. The core functionality is correctly described, but the verbosity might overwhelm users.

Consider extracting common guidance into a shared constant and referencing it, similar to how PATH_GUIDANCE and CMD_PREFIX_DESCRIPTION are used:

+const FILE_ANALYSIS_GUIDANCE = `🚨 PRIMARY TOOL FOR FILE ANALYSIS: This is the ONLY correct tool for analyzing local files (CSV, JSON, logs, etc.). The analysis tool CANNOT access local files and WILL FAIL.`;

 {
-    name: "start_process",
-    description: `
-        Start a new terminal process with intelligent state detection.
-        
-        🚨 PRIMARY TOOL FOR FILE ANALYSIS AND DATA PROCESSING
-        This is the ONLY correct tool for analyzing local files (CSV, JSON, logs, etc.).
-        The analysis tool CANNOT access local files and WILL FAIL - always use processes for file-based work.
+    name: "start_process", 
+    description: `
+        Start a new terminal process with intelligent state detection.
+        
+        ${FILE_ANALYSIS_GUIDANCE}

---

502-528: Critical guidance is valuable but could be better positioned.

The comprehensive tool selection guidance is excellent for preventing misuse. However, placing this large comment block in the middle of the tools array might affect code readability.

Consider moving this guidance to the top of the file or extracting it into a documentation comment:

+/**
+ * CRITICAL TOOL SELECTION GUIDANCE
+ * 
+ * FOR LOCAL FILE ANALYSIS (CSV, JSON, logs, data files):
+ * ✅ ALWAYS USE: start_process + interact_with_process 
+ * ✅ ALTERNATIVE: Command-line tools (read_file, search_code, cut, awk, grep)
+ * ❌ NEVER EVER USE: Analysis tool (CANNOT access local files and WILL FAIL)
+ */

             },
-                
-                // 🚨🚨🚨 CRITICAL TOOL SELECTION GUIDANCE 🚨🚨🚨
-                //
-                // FOR LOCAL FILE ANALYSIS (CSV, JSON, logs, data files):
-                // ✅ ALWAYS USE: start_process + interact_with_process 
-                // ✅ ALTERNATIVE: Command-line tools (read_file, search_code, cut, awk, grep)
-                // ❌ NEVER EVER USE: Analysis tool (CANNOT access local files and WILL FAIL)
-                //
-                // 🔴 ANALYSIS/REPL TOOL LIMITATIONS:
-                // - CANNOT read files from user's computer/file system
-                // - ONLY works with uploaded files or web data
-                // - Browser-based JavaScript runtime only
-                // - NO access to pandas, numpy, or local Python libraries
-                //
-                // 🟢 PROCESS TOOLS ADVANTAGES:
-                // - CAN access ALL local files
-                // - Full system power (Python, R, databases, etc.)
-                // - Handle files of ANY size
-                // - Access to all installed libraries and tools
-                //
-                // MANDATORY WORKFLOW FOR LOCAL FILES:
-                // 1. start_process("python3 -i") 
-                // 2. interact_with_process(pid, "import pandas as pd")
-                // 3. interact_with_process(pid, "df = pd.read_csv('/path/to/file.csv')")
-                // 4. interact_with_process(pid, "print(df.head())")
-                //
-                // REMEMBER: "For local file analysis, ALWAYS use processes, NEVER use analysis tool"

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

src/server.ts (2)

82-90: Consider simplifying the guidance format.

While the guidance is valuable, the formatting with multiple emoji alerts and repetitive emphasis may overwhelm users. Consider a more concise, professional format.

-                // 🚨🚨🚨 IMPORTANT: LOCAL FILE ANALYSIS TOOL SELECTION 🚨🚨🚨
-                // 
-                // FOR ANY LOCAL FILE WORK (CSV, JSON, logs, data analysis):
-                // ✅ ALWAYS USE: start_process + interact_with_process (with Python, R, etc.)
-                // ❌ NEVER USE: Analysis/REPL tool (CANNOT access local files and WILL FAIL)
-                //
-                // The analysis tool is browser-only and cannot read files from the user's computer.
-                // Always use processes for local file analysis!
+                // IMPORTANT: Local File Analysis Tool Selection
+                // For local file work (CSV, JSON, logs, data analysis):
+                // - Use: start_process + interact_with_process (with Python, R, etc.)
+                // - Avoid: Analysis/REPL tool (cannot access local files)
+                // The analysis tool is browser-only and cannot read local files.

---

502-528: Consolidate with earlier guidance comment.

This guidance block repeats much of the content from lines 82-90. Consider consolidating into a single, well-positioned comment block to avoid duplication.

-                // 🚨🚨🚨 CRITICAL TOOL SELECTION GUIDANCE 🚨🚨🚨
-                //
-                // FOR LOCAL FILE ANALYSIS (CSV, JSON, logs, data files):
-                // ✅ ALWAYS USE: start_process + interact_with_process 
-                // ✅ ALTERNATIVE: Command-line tools (read_file, search_code, cut, awk, grep)
-                // ❌ NEVER EVER USE: Analysis tool (CANNOT access local files and WILL FAIL)
-                //
-                // [rest of repeated content...]
+                // See tool selection guidance above

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

test/run-all-tests.js (1)

54-85: Well-designed subprocess test runner.

The function properly isolates test execution and captures comprehensive result data. Consider using process.execPath instead of 'node' to ensure the same Node.js binary is used:

-    const proc = spawn('node', [testFile], {
+    const proc = spawn(process.execPath, [testFile], {

This ensures consistency when multiple Node.js versions are installed.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro